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Abstract 


Intent is an abstract, high-level policy used to operate a network. An intent-based management 
system includes an interface for users to input requests and an engine to translate the intents 
into the network configuration and manage their life cycle. 


This document mostly discusses the concept of network intents, but other types of intents are 
also considered. Specifically, this document highlights stakeholder perspectives of intent, 
methods to classify and encode intent, and the associated intent taxonomy; it also defines 
relevant intent terms where necessary, provides a foundation for intent-related research, and 
facilitates solution development. 


This document is a product of the IRTF Network Management Research Group (NMRG). 


Status of This Memo 


This document is not an Internet Standards Track specification; it is published for informational 
purposes. 


This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the 
results of Internet-related research and development activities. These results might not be 
suitable for deployment. This RFC represents the consensus of the Network Management 
Research Group of the Internet Research Task Force (IRTF). Documents approved for publication 
by the IRSG are not candidates for any level of Internet Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 
on it may be obtained at https://www.rfc-editor.org/info/rfc9316. 
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1. Introduction 


The vision of intent-based networks has attracted a lot of attention because it promises to 
simplify the management of networks by human operators. This is done by simply specifying 
what should happen on the network without giving any instructions on how to do it. This 
promise caused many researcher-led activities and telecom companies to start researching this 
new vision and many Standards Development Organizations (SDOs) to propose different intent 
frameworks. 


This document proposes an intent classification methodology and an intent taxonomy. The scope 
of these proposals is to ensure a common understanding in the research community in terms of 
what the intent users, intent types, or intent solutions, etc., are for specific scenarios that are 
being considered. 
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The document represents the consensus of the Network Management Research Group (NMRG). It 
has been reviewed extensively by the Research Group (RG) members who are actively involved 
in the research and development of the technology covered by this document. It is not an IETF 
product and is not a standard. 


1.1. Research Activities 


Intent-based networking is an active research topic spanning across different areas that could 
benefit from an intent classification and taxonomy. 


Some examples include: 


* intent expression and recognition ([Bezahaf21], [Bezahaf19], [Jacobs18]). The use of a 
common classification could provide consistency in the understanding of the various forms 
of intent expressions being proposed and investigated. 


e the orchestration of cognitive autonomous radio access networks (RANs) [Banerjee21] where 
intents are classified based on their content. 


* intent network verification [Tian19], where the authors are working to propose new intent 
language. 


Furthermore, this document is already proving to be extremely relevant to the research 
community as it has been used as the basis for proposing self-generated Intent-based systems 
[Bezahaf19], for advancing Virtual Network Function (VNF) placement solutions based on 
Internet-Based Networks (IBNs) that rely on defining user intent profiles corresponding to 
abstract network services [Leivadeas21], for improving existing solutions in provisioning intent- 
based networks, for proposing new approaches to service management [Davoli21], and even for 
defining grammars for users to specify the high-level requirements for blockchain selection in 
the form of intent [Padovan20]. As well, the document has been mentioned in surveys addressing 
the topic of intelligent intent-based autonomous networks [Mehmood21] [Szilagyi21]. 


This document also describes an example on how this proposal has been successfully applied in 
an academic environment [POC-IBN] by researchers in the area of Software-Defined Networking 
/ Network Function Virtualization (SDN/NFV) for defining the scope of their project. The specific 
problem addressed by researchers is how to apply intent concepts at different levels that 
correspond to different stakeholders. 


The IEEE Communications Society Technical Committee on Network Operation and Management 
(IEEE-CNOM), IRTF Network Management Research Group, and IFIP WG6.6 have developed a 
taxonomy for network and service management [IFIP-NSM] that is used by the research 
community in network management and operations to structure the research area through a 
well-defined set of keywords and to improve quality of reviews in submissions to journals, 
conferences, and workshops. The proposed intent taxonomy may be contributed as an extension 
to this taxonomy for intent-driven management. 
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1.2. Standards and Open-Source Activities 


Several SDOs and open-source projects, such as the IRTF NMRG, Open Networking Foundation 
(ONF) [ONF] / Open Network Operating System (ONOS) [ONOS], European Telecommunications 
Standards Institute (ETSI) / Experiential Networked Intelligence (END, and TMF with its 
autonomous networks, have proposed intents for defining a set of network operations to execute 
in a declarative manner. 


More recently, the IRTF NMRG is working on "Intent-Based Networking - Concepts and 
Definitions" [RFC9315]. This document clarifies the concept of "Intent" and provides an overview 
of the functionality that is associated with it. The goal is to contribute towards a common and 
shared understanding of terms, concepts, and functionality that can be used as the foundation to 
guide further definition of associated research and engineering problems and their solutions. 


The present document, together with [RFC9315], aims to become the foundation for future intent- 
related topic discussions regarding the NMRG. 


The SDOs usually come up with their own way of specifying an intent and their own 
understanding of what an intent is. Additionally, each SDO defines a set of terms and level of 
abstraction, its intent users, and the applications and usage scenarios. 


However, most intent approaches proposed by SDOs share the same features: 


* It must be declarative in nature, meaning that an intent user specifies the goal on the 
network without specifying how to achieve that goal. 

* It must be vendor agnostic in the sense that it abstracts the network capabilities or the 
network infrastructure from the intent user, and it can be ported across different platforms. 

* It must provide an easy-to-use interface, which simplifies the interaction of the intent users 
with the intent system through the usage of familiar terminology or concepts. 

* It should be able to detect and resolve intent conflicts, which include, for example, static 
(compile-time) conflicts and dynamic (run-time) conflicts. 


1.3. Scope 


The focus of this document is on the definition of criteria enabling the categorization of intents 
from viewpoint of the stakeholders. Concepts and definitions related to IBN are provided in 
[RFC9315]. 


This document mostly addresses intents in the context of network intents; however, other types 
of intents are not excluded, as presented in Sections 4.4 and 6.2. 


It is impossible to fully differentiate intents only by the common characteristics followed by 
concepts, terms, and intentions. This document clarifies what an intent represents for different 
stakeholders through a classification on various dimensions, such as solutions, intent users, and 
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intent types. This classification ensures common understanding among all participants and is 
used to determine the scope and priority of individual projects, proof of concepts (PoCs), 
research initiatives, or open-source projects. 


The scope of intent classification in this document includes solutions, intent users, and intent 
types; the initial classification table is made according to this scope. The methodology presented 
can be used to update the classification tables by adding or removing different solutions, intent 
users, or intent types to cater to future scenarios, applications, or domains. 


2. Abbreviations 


AI: Artificial Intelligence 

CE: Customer Equipment 

CFS: Customer Facing Service 

CLI: Command-Line Interface 

DB: Database 

DC: Data Center 

ECA: Event Condition Action 

GBP: Group-Based Policy 

GPU: Graphics Processing Unit 

IBN: Intent-Based Network 

NFV: Network Function Virtualization 
O&M: OAM & Maintenance 

ONF: Open Networking Foundation 

ONOS: Open Network Operating System 
PNF: Physical Network Function 

QoE: Quality of Experience 

RFS: Resource Facing Service 

SDO: Standards Development Organization 
SD-WAN: Software-Defined Wide-Area Network 
SLA: Service Level Agreement 


SUPA: Simplified Use of Policy Abstractions 
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VM: Virtual Machine 


VNF: Virtual Network Function 


3. Definitions 


A common and shared understanding of terms and definitions related to IBN is provided in 
[RFC9315] as follows: 


Intent: A set of operational goals (that a network should meet) and outcomes (that a network is 
supposed to deliver) defined in a declarative manner without specifying how to achieve or 
implement them. 


Intent-Based Network: A network that can be managed using intent. 
Policy: A set of rules that governs the choices in behavior of a system. 


Intent User: A user that defines and issues the intent request to the intent-based management 
system. 


Other definitions relevant to this document, such as intent scope, intent network scope, intent 
abstraction, intent abstraction, and intent life cycle are available in Section 5. 


4. Abstract Intent Requirements 


In order to understand the different intent requirements that would drive intent classification, 
we first need to understand what intent means for different intent users. 


4.1. What is intent? 


The term "Intent" has become very widely used in the industry for different purposes; sometimes 
its use is not even in agreement with SDO-shared principles mentioned in Section 1. [RFC9315] 
brings clarification with relation to what an intent is and how it differentiates from policies and 
services. 


Different stakeholders have different perspectives of the network; therefore, they have different 
intent requirements. Their intent is sometimes technical, non-technical, abstract, or technology 
specific. Therefore, it is important to start a discussion in the industry and academic 
communities about what intent is for different solutions and intent users. It is also imperative to 
try to propose some intent categories/classifications that could be understood by a wider 
audience. This would help us define intent interfaces, domain-specific languages, and models. 
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4.2. Intent Solutions and Intent Users 


Intent types are defined by all aspects that are required to profile different requirements to 
easily distinguish between them. However, in order to facilitate a clustered classification, we can 
focus on two aspects: the solution and intent user. They can be considered to be the main keys to 
classify intents, as we can easily group requirements by solution and intent user. 


On the one hand, different solutions and intent users have different requirements, expectations, 
and priorities for intent-based networking. Therefore, intent users require different intent types, 
depending on their context, since they participate in different use cases. For instance, some 
intent users are more technical and require intents that expose more technical information. 
Other intent users do not have knowledge of the network infrastructure and require intents that 
shield them from different networking concepts and technologies. 


The following are the solutions and intent users that intent-based networking needs to support: 


Solutions Intent Users 

Carrier Network Operators, Service Designers / App Developers, Service 
Networks Operators, Customers / Subscribers 

DC Networks Cloud Administrators, Underlay Network Administrators, Application 


Developers, Customers / Tenants 


Enterprise Enterprise Administrators, Application Developers, End Users 
Networks 


Table 1: Intent Solutions and Intent Users 


These intent solutions and intent users represent a starting point for the classification and are 
expendable through the methodology presented in Section 6.1. 


* For carrier network scenarios, for example, if a customer/subscriber wants to watch high- 
definition video, then the intent is to convert the video image to 1080p. 


* For DC network scenarios, administrators have their own clear network intent such as load 
balancing. For all traffic flows that need NFV service chaining, they can restrict the 
maximum load of any VNF node / container below 50% and the maximum load of any 
network link below 70%. 


* For enterprise network scenarios, when hosting a video conference, multiple remote 
accesses are required. An example of the intent from the network administrator is as 
follows: for any end user of this application, the arrival time of hologram objects of all the 
remote tele-presenters should be synchronized within 50 ms to reach the destination viewer 
for each conversation session. 
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4.3. Benefits of Intents for Different Stakeholders 


Current network APIs and CLIs are too complex because they are highly integrated with the low- 
level concepts exposed by networks. Customers, application developers, and end users must not 
be required to set IP addresses, VLANs, subnets, or ports, whereas operators may still want to 
have both more technical and network visibility. All stakeholders would benefit from simpler 
interfaces, such as: 


* request gold VPN service between sites A, B, and C 
* provide CE redundancy for the customer sites 
* add access rules to the network service 


Operators and administrators manually troubleshoot and fix their networks and services. They 
instead want to: 


* simplify and automate network operations 

e simplify definitions of network services 

* provide simple customer APIs for value-added services (operators) 

* be informed if the network or service is not behaving as requested 

* enable automatic optimization and correction for selected scenarios 
* have systems that learn from historic information and behavior 


Currently, intent users cannot build their own services and policies without becoming technical 
experts and performing manual maintenance actions. They instead want to be able to: 


* build their own network services with their own policies via simple interfaces, without 
becoming networking experts 


* have their network services up and running based on intent and automation only, without 
any manual actions or maintenance 


4.4. Intent Types That Need to Be Supported 


Next to the intent solutions and intent users, another way to categorize the intent is through the 
intent types. The following intent types and subtypes need to be supported in order to address 
the requirements from different solutions and intent users. 


* Customer service intent 
o for customer self service with SLA 


o for service operator orders 


* Network and underlay network service intent 
o for service operator orders 


o for intent-driven network configuration, verification, correction, and optimization 
o for intent created and provided by the underlay network administrator 
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* Network and underlay network intent 
o for network configuration 


o for automated life-cycle management of network configurations 
o for network resources (switches, routers, routing, policies, and underlay) 


* Cloud management intent 
° for DC configuration, VMs, DB servers, and Application servers 


o for communication between VMs 


* Cloud resource management intent 
o for cloud resource life-cycle management (policy-driven self-configuration and auto- 
scaling and recovery/optimization) 


* Strategy intent 
o for security, QoS, application policies, traffic steering, etc. 


° for configuring and monitoring policies, alarm generation for non-compliance, and auto- 
recovery 


o for design models and policies for network and network service design 
° for design workflows, models, and policies for operational task intents 


* Operational task intents 
o for network migration 


o for device replacements 
o for network software upgrades 
o for automating any other tasks that operators/administrator often perform 


It is important to mention all of the previously mentioned types and subtypes may affect other 
intents. For example, operational task intent can modify many other intents. The task itself is 
short lived, but the modification of other intents has an impact on their life cycle, so those 
changes must continue to be continuously monitored and self corrected/optimized. 


5. Functional Characteristics and Behavior 


Intent can be used to operate immediately on a target (much like issuing a command) or 
whenever it is appropriate (e.g., in response to an event). In either case, intent has a number of 
behaviors that serve to further organize its purpose, as described by the following subsections. 


5.1. Abstracting Intent Operation 


The modeling of intents can be abstracted using the following three-tuple: 
(Context, Capabilities, Constraints) 


* Context grounds the intent and determines if it is relevant or not for the current situation. 
Thus, context selects intents based on applicability. 
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* Capabilities describe the functionality that the intent can perform. Capabilities take different 
forms depending on the expressivity of the intent as well as the programming paradigm(s) 
used. 


* Constraints define any restrictions on the capabilities to be used for that particular context. 


Metadata can be attached via strategy templates to each of the elements of the three-tuple and 
may be used to describe how the intent should be used and how it operates as well as prescribe 
any operational dependencies that must be taken into account. 


Although different intent categories share the same abstracted intent model, each category will 
have its own specific context, capabilities, and constraints. 


5.2. Intent User Types 


Expanding on the introduction in Section 4.2, intent user types represent the intent users that 
define and issue the intent request. Depending on the intent solutions, there are specific intent 
users. Examples of intent users are customers, network operators, service operators, enterprise 
administrators, cloud administrators, underlay network administrators, or application 
developers. 


* Customers and end users do not necessarily know the functional and operational details of 
the network that they are using. Furthermore, they lack skills to understand such details; in 
fact, such knowledge is typically not relevant to their job. In addition, the network may not 
expose these details to its intent users. This class of intent users focuses on the applications 
that they run and uses services offered by the network. Hence, they want to specify policies 
that provide consistent behavior according to their business needs. They do not have to 
worry about how the intents are deployed onto the underlying network and especially 
whether the intents need to be translated to different forms to enable network elements to 
understand them. 


Application developers work in a set of abstractions defined by their application and 
programming environment(s). For example, many application developers think in terms of 
objects (e.g., a VPN). While this makes sense to the application developer, most network 
devices do not have a VPN object per se; rather, the VPN is formed through a set of 
configuration statements for that device in concert with configuration statements for the 
other devices that together make up the VPN. Hence, the view of application developers 
matches the services provided by the network but may not directly correspond to other 
views of other intent users. 


* Network operators may have the knowledge of the underlying network. However, they may 
not understand the details of the applications and services of customers. 


5.3. Intent Scope 


Intents are used to manage the behavior of the networks they are applied to and all intents are 
applied within a specific scope, such as: 


* connectivity scope, if the intent creates or modifies a connection 
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* security/privacy scope, if the intent specifies the security characteristics of the network, 
customers, or end users 


* application scope, when the intent specifies the applications to be affected by the intent 
request 


* QoS scope, when the intent specifies the QoS characteristics of the network 


These intent scopes are expendable through the methodology presented in Section 6.1. 


5.4. Intent Network Scope 


Regardless of the intent user type, their intent request affects the network, or network 
components, which are representing the intent targets. 


Thus, the intent network scope, or policy target as known in the area of declarative policy, can 
represent VNFs or PNFs, physical network elements, campus networks, SD-WANSs, RANS, cloud 
edges, cloud cores, branches, etc. 


5.5. Intent Abstraction 


Intent can be classified by whether it is necessary to feed back technical network information or 
non-technical information to the intent user after the intent is executed. As well, intent 
abstraction covers the level of technical details in the intent itself. 


* Non-technical intent users do not care how the intent is executed nor do they care about the 
details of the network. As a result, they do not need to know the configuration information of 
the underlying network. They only focus on whether the intent execution result achieves the 
goal and the execution effect such as the quality of completion and the length of execution. 
In this scenario, we refer to an abstraction without technical feedback. 

* Administrators, such as network administrators, perform intents, such as allocating network 
resources, selecting transmission paths, handling network failures, etc. They require 
multiple feedback indicators for network resource conditions, congestion conditions, fault 
conditions, etc., after execution. In this case, we refer to an abstraction with technical 
feedback. 


As per the definition of "intent" provided in [RFC9315], lower-level intents are not considered to 
qualify as intents. However, we kept this classification to identify any PoCs / Demos / Use Cases 
that still either require or implement a lower level of abstraction for intents. 


5.6. Intent Life Cycle 


Intents can be classified into transient and persistent intents: 


Transient: The intent has no life-cycle management. As soon as the specified operation is 
successfully carried out, the intent is finished and can no longer affect the target object. 
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Persistent: The intent has life-cycle management. Once the intent is successfully activated and 
deployed, the system will keep all relevant intents active until they are deactivated or 
removed. 


5.7. Autonomous Driving Levels 


In different phases of the autonomous driving network [TMF-AUTO], the intents are different. 
Depending on the Autonomous Network Level of the overall solution, we may have different 
intent requirements and types. For example, at lower levels, the customer intent is: 


* automatically converted to configuration policies only while at the higher levels, 
* covering the full life cycle, 

* converted to both configuration and monitoring policies, and 

* self assured using AI. 


Typical examples of autonomous driving networks level 0 to 5 are shown below. 

Level 0 - Traditional manual network: 
O&M personnel manually control the network and obtain network alarms and logs. 
- No intent 


Level 1 - Partially automated network: 
Automated scripts are used to automate service provisioning, network deployment, and 
maintenance. The network provides shallow perception of the network status and decision 
making suggestions. 


- No intent 


Level 2 - Automated network: 
This entails the automation of most service provisioning, network deployment, and 
maintenance of a comprehensive perception of network status and local machine decision- 
making. 


- simple intent on service provisioning 


Level 3 - Self-optimization network: 
This entails a deep awareness of network status and automatic network control, meeting 
requirements of intent users of the network. 


- Intent based on network status cognition 


Level 4 - Partial autonomous network: 
In a limited environment, people do not need to participate in decision-making and networks 
can adjust themselves. 


- Intent based on limited AI 
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Level 5 - Autonomous network: 
In different network environments and network conditions, the network can automatically 
adapt and adjust to meet people's intentions. 


- Intent based on AI 


6. Intent Classification 


This section proposes an approach to intent classification that may help to classify mainstream 
intent-related demos/tools. 


The three classifications in this document have been proposed from scratch (following the 
methodology presented) through three iterations: one for a carrier network intent solution, one 
for a DC intent solution, and one for an enterprise intent solution. For each intent solution, we 
identified the specific intent users and intent types. Then, we further identified intent scope, 
network scope, abstractions, and life-cycle requirements. 


These classifications and the generated tables can be easily extended. For example, for the DC 
intent solution, a new category "resource scope" is identified, and the classification table has 
been extended accordingly. 


In the future, as new scenarios, applications, and domains emerge, new classifications and 
taxonomies can be identified, following the proposed methodology. 


The intent classifications have been documented to the best of our knowledge at the time of 
writing. Additional classifications will most likely come to light in the future. 


The output of the intent classification is the intent taxonomy introduced in the subsections of this 
section. 


Thus, the subsections of Section 6 introduce the proposed intent classification methodology, the 
consolidated intent taxonomy for three intent solutions, and the concrete examples of intent 
classifications for three different intent solutions (e.g., carrier network, data center, and 
enterprise) that were derived using the proposed methodology and can be filled in for PoCs, 
demos, research projects, or future documents. 


6.1. Intent Classification Methodology 


This section describes the methodology used to derive the initial classification proposed in the 
document. The proposed methodology can be used to create new intent classifications from 
scratch by analyzing the solution knowledge. As well, the methodology can be used to update 
existing classification tables by adding or removing different solutions, intent users, or intent 
types in order to cater to future scenarios, applications, or domains. 
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Figure 1: Intent Classification Methodology 
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The intent classification workflow starts from the solution knowledge, which can provide 
information on requirements, use cases, technologies used, network properties, intent users that 
define and issue the intent request, and requirements. The following defines the steps to classify 


an intent: 


1. Receive the information provided in the solution knowledge as input for identifying the 
intent solution (e.g., carrier, enterprise, and data center). Intent solutions are reviewed 
against the existing classification and can either be used if present or added if not there; if 
not needed, they can be removed from the classification (R1-U1). 
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N 


. Identify the intent user types (e.g., customer, network operators, service operators, etc.). 
Review the existing intent classification. Then use the intent user type if present; add it if it is 
not there or remove it if not needed (R2-U2). 


Ww 


. Identify the types of intent (e.g., network intent, customer service intent). Review the existing 
classification and then use, add, or remove the intent type (R3-U3). 

4. Identify the intent scopes (e.g., connectivity, application) based on the solution knowledge. 
Then, review the existing classification. Use, add, or remove the identified intent scope (R4- 
U4). 

. Identify the network scopes (e.g., campus, radio access). Then, review the existing 
classification. Either use, add, or remove the identified network scope (R5-U5). 


LH 


(ep) 


. Identify the abstractions (e.g., technical, non-technical). Then, review the existing 
classification and either use, add, or remove the abstractions (R6-U6). 


-l 


. Identify the life-cycle requirements (e.g., persistent, transient). Then, review the existing 
classification. Either use, add, or remove the life-cycle requirements (R7-U7). 


8. Identify any new categories. Use and add the newly identified categories. New categories can 
be identified as new domains or applications emerge or as new areas of concern (e.g., 
privacy, compliance) arise that are not listed in the current methodology. 


6.2. Intent Taxonomy 


The following taxonomy describes the various intent solutions, intent user types, intent types, 
intent scopes, network scopes, abstractions, and life cycles. The taxonomy represents the output 
of the intent classification tables for each of the solutions addressed (i.e., carrier, data center, and 
enterprise solutions). 


The intent scope categories in Figure 2 are shared among the carrier, DC, and enterprise 
solutions. The abbreviations (Cx) in Sections 6.3.2 and 6.4.2 are introduced with the scope of 
fitting as column title in the following tables. 
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6.3. Intent Classification 


6.3.1. Intent Users and Intent 


Intent Classification 
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+--+ +>|Technical Non-Technical | 
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This section addresses steps 1, 2, and 3 from Figure 1. The following table describes the intent 
users in carrier solutions and intent types with their descriptions for different intent users. 
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Intent Type Description 


Customer self service with SLA and value-added service. 
Example: Always maintain a high quality of service and high 
bandwidth for gold-level subscribers. 

Operation statement: Measure the network congestion 
status, give different adaptive parameters to stations of 
different priority; thus, in a heavy load situation, make the 
bandwidth of the high-priority customers guaranteed. At the 
same time, ensure the overall utilization of the system and 
improve the overall throughput of the system. 


Customer designs models and policy intents to be used by 
customer service intents. 

Example: Request reliable service during peak traffic 
periods for video-type apps. 


Service provided by the network service operator to the 
customer (e.g., the service operator). 

Example: Request network service with delay guarantee for 
access customer A. 


Network operator requests network-wide (service underlay 
or other network-wide configuration) or network-resource 
configurations (switches, routers, routing, or policies). 
Includes connectivity, routing, QoS, security, application 
policies, traffic steering policies, alarm generation for non- 
compliance, auto-recovery, etc. 

Example: Request high priority queuing for traffic of class A. 


Network operator requests execution of any automated task 
other than network service intent and network intent (e.g., 
network migration, server replacements, device 
replacements, or network software upgrades). 

Example: Request migration of all services in network N to 
backup path P. 


Network operator designs models, policy intents, and 
workflows to be used by network service intents, network 
intents, and operational task intents. Workflows can 
automate any tasks that the network operator often 
performs in addition to network service intents and 
network intents. 

Example: Ensure the load on any link in the network is not 
higher than 50%. 
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Intent Type Description 


Service operator's customer orders, customer service, or 
SLA. 

Example: Provide service S with guaranteed bandwidth for 
customer A. 


Service operator's network orders / network SLA. 
Example: Provide network guarantees in terms of security, 
low latency, and high bandwidth. 


Service operator requests execution of any automated task 
other than customer service intent and network service 
intent. 

Example: Update service operator portal platforms and their 
software regularly. Move services from network operator 1 
to network operator 2. 


Service operator designs models, policy intents, and 
workflows to be used by customer service intents, network 
service intents, and operational task intents. Workflows can 
automate any task that the service operator often performs 
in addition to network service intents and network intents. 
Example: Request network service guarantee to avoid 
network congestion during special periods such as Black 
Friday and Christmas. 


Customer service intent API provided to the application 
developers. 
Example: API to request network to watch HD video (4K/8K). 


Network service intent API provided to the application 
developers. 

Example: API to request network service, monitoring, and 
traffic grooming. 


Network intent API provided to the application developers. 
Example: API to request network resource configurations. 


Operational task intent API provided to the application 
developers. This is for the trusted internal operator / service 
providers / customer DevOps. 

Example: API to request server migrations. 
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Intent User Intent Type Intent Type Description 


Strategy Application developer designs models, policy, and 

Intent workflows to be used by customer service intents, network 
service intents, and operational task intents. This is for the 
trusted internal operator / service provider / customer 
DevOps. 
Example: API to design network load-balancing strategies 
during peak times. 


Table 2: Intent Classification for Carrier Solution 


6.3.2. Intent Categories 


This subsection addresses steps 4 to 7 from Figure 1. The following are the proposed categories: 


Intent Scope: C1=Connectivity, C2-Security/Privacy, C3=Application, C4=QoS 
Network Scope: 


Network Domain: (C1=Radio Access, C2=Transport Access, C3-Transport Aggregation, 
C4=Transport Core, C5=Cloud Edge, C6=Cloud Core 


Network Function (NF) Scope: C1-VNFs, C2=PNFs 


Abstraction (ABS): C1-Technical (with technical feedback), C2=Non-technical (without technical 
feedback) (see Section 5.2). 


Life cycle (L-C): C1=Persistent (full life cycle), C27 Transient (short lived) 


6.3.3. Intent Classification Example 


This section contains an example of how the methodology described in Section 6.1 can be used in 
order to classify intents introduced in the "A Multi-Level Approach to IBN" PoC demonstration 
[POC-IBN]. This PoC is led by academics carrying out research in the area of SDN/NFV, and the 
Specific problem they are addressing is the application of the intent concept at different levels 
that correspond to different stakeholders. For this research work, they considered two types of 
intents: slice intents and service chain intents. 


In this PoC [POC-IBN], a slice intent expresses a request for a network slice with two types of 
components: a set of top-layer virtual functions and a set of virtual switches and/or routers of L2/ 
L3 VNFs. A service chain intent expresses a request for a service operated through a chain of 
service components running in L4-L7 virtual functions. 


Following the intent classification methodology described step by step in Section 6.1, the 
following can be derived: 


1. The intent solution for both intents is carrier network. 


2. The intent user type is network operator for the slice intent and service operator for the 
service chain intent. 
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3. The type of intent is a network service intent for the slice intent and a customer service 
intent for the service chain intent. 


4. The intent scopes are connectivity and application. 
5. The network scope is VNF, cloud edge, and cloud core. 


6. The abstractions are with technical feedback for the slice intent and without technical 
feedback for the service chain intent. 


7. The life cycle is persistent. 


The following table shows how to represent this information in a tabular form. The "X" in the 
table refers to the slice intent; the "Y" in the table refers to the service chain intent. 
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Figure 3: Intent Classification Example for Carrier Solution 


6.4. Intent Classification for Data Center Network Solutions 


6.4.1. Intent Users and Intent Types 


The following table describes the intent users in DC network solutions and intent types with their 
descriptions for different intent users. 


Intent User Intent Type Intent Type Description 
Customer/ Customer Customer self service via tenant portal. 
Tenants Service Example: Request GPU computing and storage 


resources to meet 10k video surveillance services. 


Strategy Intent This includes models and policy intents designed by 
customers/tenants to be reused later during 
instantiation. 

Example: Request dynamic computing and storage 
resources of the service in special and daily times. 


Cloud Cloud Configuration of VMs, DB Servers, app servers, and 
Administrator Management communication between servers and VMs. 
Intent Example: Request connectivity between VMs A, B, and C 


in network N1. 


Cloud Policy-driven self configuration and recovery/ 
Resource optimization. 

Management Example: Request automatic life-cycle management of 
Intent VM cloud resources. 

Operational Cloud administrator requests execution of any 

Task Intent automated task other than cloud management intents 


and cloud resource management intents. 

Example: Request upgrade operating system to version 
X on all VMs in network N1. 

Operational statement: An intent to update a system 
might reconfigure the system topology (connect to a 
service and to peers), exchange data (update the 
content), and uphold a certain QoE level (allocate 
sufficient network resources). Thus, the network carries 
out the necessary configuration to best serve such an 
intent, e.g., setting up direct connections between 
terminals and allocating fair shares of router queues 
considering other network services. 
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Intent Type Description 


Cloud administrator designs models, policy intents, and 
workflows to be used by other intents. Automate any 
tasks that administrator often performs in addition to 
life cycle of cloud management intents and cloud 
management resource intents. 

Example: In case of emergency, automatically migrate 
all cloud resources to DC2. 


Service created and provided by the underlay network 
administrator. 

Example: Request underlay service between DC1 and 
DC2 with bandwidth B. 


Underlay network administrator requests some DCN- 
wide underlay network configuration or network 
resource configurations. 

Example: Establish and allocate DHCP address pool. 


Underlay network administrator requests execution of 
any automated task other than underlay network 
service and resource intent. 

Example: Request automatic rapid detection of device 
failures and pre-alarm correlation. 


Underlay network administrator designs models, policy 
intents, and workflows to be used by other intents. 
Automate any tasks that the administrator often 
performs. 

Example: For all traffic flows that need NFV service 
chaining, restrict the maximum load of any VNF node/ 
container below 50% and the maximum load of any 
network link below 70%. 


Cloud management intent API provided to the 
application developers. 

Example: API to request configuration of VMs or DB 
Servers. 


Cloud resource management intent API provided to the 
application developers. 

Example: API to request automatic life-cycle 
management of cloud resources. 
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Intent User Intent Type Intent Type Description 
Underlay Underlay network service API provided to the 
Network application developers. 
Service Intent Example: API to request real-time monitoring of device 

condition. 

Underlay Underlay network resource API provided to the 
Network application developers. 
Intent Example: API to request dynamic management of IPv4 


address pool resources. 


Operational Operational task intent API provided to the trusted 
Task Intent application developer (internal DevOps). 
Example: API to request automatic rapid detection of 
device failures and pre-alarm correlation. 


Strategy Intent Application developer designs models, policy intents, 
and building blocks to be used by other intents. This is 
for the trusted internal DCN DevOps. 

Example: API to request load-balancing thresholds. 


Table 3: Intent Classification for Data Center Network Solutions 


6.4.2. Intent Categories 


The following are the proposed categories: 


Intent Scope: C1=Connectivity, C2=Security/Privacy, C3=Application, C4=QoS, C5=Storage, 
C6-Compute 


Network Scope 
Network Domain: DC Network 
DCN Network (DCN Net) Scope: C1=Logical, C2=Physical 
DCN Resource (DCN Res) Scope: C1-Virtual, C2=Physical 


Abstraction (ABS): C1=Technical (with technical feedback), C2=Non-technical (without technical 
feedback) (see Section 5.2). 


Life cycle (L-C): Ci-Persistent (full life cycle), C27 Transient (short lived) 


6.4.3. Intent Classification Example 


This section depicts an example on how the methodology described in Section 6.1 can be used by 
the research community to classify intents. As mentioned in Section 6.3.3, a successful use of the 
classification proposed in this document is introduced in the PoC demonstration titled "A Multi- 
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Level Approach to IBN" [POC-IBN]. The PoC is led by academics carrying out research in the area 
of SDN/NFV; the specific problem they are addressing is the application of the intent concept at 
different levels that correspond to different stakeholders. 


For their research work, they considered two types of intents: slice intents and service chain 
intents. For the data center solution, only the slice intent is relevant. 


As already mentioned in Section 6.3.3, a slice intent expresses a request for a network slice with 
two types of components: a set of top-layer virtual functions and a set of virtual switches and/or 
routers of L2/L3 VNFs. 


Following the intent classification methodology described step by step in Section 6.1, we identify 
the following: 


1. The intent solution is data center. 

2. The intent user type is the cloud administrator for the slice intent and service chain intent. 
3. The type of intent is a cloud management intent for the slice intent. 

4. The intent scopes are connectivity and application. 

5. The network scope is logical; the resource scope is virtual. 

6. The abstractions are with technical feedback for the slice intent. 

7. The life cycle is persistent. 


The following table shows how to represent this information in a tabular form; the "X" in the 
table refers to the slice intent. 
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Figure 4: Intent Classification Example for Data Center Network Solutions 


6.5. Intent Classification for Enterprise Solution 


6.5.1. Intent Users and Intent Types 


The following table describes the intent users in enterprise solutions and their intent types. 


Intent User Intent Type Intent Type Description 

End User Customer Enterprise end user self service or applications; 
Service enterprise may have multiple types of end users. 
Intent Example: Request access to VPN service. Request video 


conference between end user A and B. 


Strategy This includes models and policy intents designed by 
Intent end users to be used by end-user intents and their 
applications. 
Example: Create a video conference type for a weekly 
meeting. 
Enterprise Network Service provided by the administrator to the end users 
Administrator Service and their applications. 
(internal or MSP) Intent Example: For any end user of application X, the arrival 


of hologram objects of all the remote tele-presenters 
should be synchronized within 50 ms to reach the 
destination viewer for each conversation session. 
Create management VPN connectivity for type of 
service A. 

Operational statement: The job of the network layer is 
to ensure that the delay is between 50-70 ms through 
the routing algorithm. At the same time, the node 
resources need to meet the bandwidth requirements 
of 4K video conferences. 
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Intent Type Description 


Administrator requires network-wide configuration 
(e.g., underlay or campus) or resource configuration 
(switches, routers, or policies). 

Example: Configure switches in campus network 1 to 
prioritize traffic of type A. Configure YouTube as 
business non-relevant. 


Administrator requests execution of any automated 
task other than network service intents and network 
intents. 

Example: Request network security automated tasks 
such as web filtering and DDoS cloud protection. 


Administrator designs models, policy intents, and 
workflows to be used by other intents. Automate any 
tasks that the administrator often performs. 
Example: In case of emergency, automatically shift all 
traffic of type A through network N. 


End-user service / application intent API provided to 
the application developers. 
Example: API for request to open a VPN service. 


Network service API provided to application 
developers. 

Example: API for request network bandwidth and 
latency for hosting a video conference. 


Network API provided to application developers. 
Example: API for requesting network device 
configuration. 


Operational task intent API provided to the trusted 
application developer (internal DevOps). 

Example: API for requesting automatic monitoring 
and interception for network security. 


Application developer designs models, policy intents, 
and building blocks to be used by other intents. This is 
for the trusted internal DevOps. 

Example: API for strategy intent in case of 
emergencies. 


Table 4: Intent Classification for Enterprise Solution 
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6.5.2. Intent Categories 


The following are the proposed categories: 


Intent Scope: C1=Connectivity, C2-Security/Privacy, C3=Application, C4=QoS 
Network (Net) Scope: C1-Campus, C2-Branch, C3=SD-WAN 


Abstraction (ABS): C1=Technical (with technical feedback), C2=Non-technical (without technical 
feedback) (see Section 5.2) 


Life cycle (L-C): C1=Persistent (full life cycle), C2=Transient (short lived) 


The following is the intent classification table example for enterprise solutions. 
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Figure 5: Intent Categories for Enterprise Solution 
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This document is aligned with the RG objectives and supports investigations into intent-based 
networking by proposing an intent categorization methodology and taxonomy. It brings 


clarification to what an intent represents for different stakeholders through the proposal of an 
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intent classification approach, ensuring that a common understanding among all the participants 
exists. This, together with the proposed intent taxonomy provides a solid foundation for future 
intent-related discussions within the NMRG. 


The benefits of this intent classification document in the research community have been 
demonstrated through a PoC implementation [POC-IBN] in which the document's concepts have 
been applied at different levels corresponding to different stakeholders. 


8. Security Considerations 


This document identifies security and privacy as categories of the intent scope. The intents could 
be solely security intents and privacy intents, or security can be embedded in the intents that 
include also connectivity, application, and QoS scope. 


Security and privacy scope is when the intent specifies the security characteristics of the 
network, customers, or end users, and privacy for customers and end users. 


More details of these security intents will be described in future documents that specify 
architecture, functionality, user intents, and models. An analysis of the security considerations of 
the overall intent-based system is provided in Section 9 of [RFC9315]. 


9. IANA Considerations 


This document has no IANA actions. 
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